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(54) Microprocessor with debugging system 

(57) A system provides debugging functions for high- 
speed processors by adding a comparatively small 
amount of hardware to the microprocessor. A debugging 
module which receives part of the debugging function is 
placed in a microprocessor and is connected with a 
debugging tool outside the processor. In the debugging 
module, a processor core in the processor accesses and 





executes a monitor program in the debugging tool 60 
through the debugging module. In the normal mode, 
while the processor executes a user program, the debug- 
ging module receives trace information and sends it to 
the debugging tool and also performs tasks related to the 
breakpoints. 
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Description 

Field of The Invention 

The present invention concerns a debugging system 
for debugging microcomputer application systems. 

Background of the Art 



processor bus 90 of microprocessor 10 on user target 
system 70 , accesses to memory 40 and I/O 50 of micro- 
processor 10 can be traced. 

Since the operations and circuit structures of the 
5 examples of the prior art explained in Figs. 1 through 4 
are well known to those skilled in the art, no further expla- 
nation will be provided here. 



Fig. 1 shows example 1 of the prior art which is a 
debugging system that is generally called a ROM moni- 
tor. A serial interface 80 for connecting with a host com- 
puter 90 is provided on a user target system 70, and a 
monitor program 41 is stored in memory 40. Microproc- 
essor 10 accesses I/O 50, memory 40, and register 1 1 
by running monitor program 41 . Furthermore, execution 
control of user programs is performed by using software 
break instructions. 

Fig. 2 shows example 2 of the prior art. A serial inter- 
face 12, needed for communication with debugging tool 
100, and a sequencer 13 for interpreting and executing 
the electrical signals sent from the debugging tool 100, 
are contained in microprocessor 10 on user target sys- 
tem 70. According to received signals, sequencer 13 
temporarily halts the execution of the user program's 
accessing of register 11, or accessing of memory 40 or 
I/O 50 by using bus controller 1 4. Furthermore, execution 
control of user programs is performed by using hardware 
break points or software break instructions. 

Since signals from serial interface 12 often cannot 
be connected directly to host computer 90, debugging 
tool 100 converts the commands from host computer 90 
to electrical signals that can be connected directly to 
microprocessor 10. and converts signals from micro- 
processor 10 to a data format host computer 90 under- 
stands. 

Fig. 3 shows example 3 of the prior art which is a 
debugging system that is generally called an in-circuit 
emulator. During debugging, microprocessor 10 on user 
target board system 70 is removed or made inactive, and 
the probe of debugging tool 1 1 0 is connected thereto for 
running debugging microprocessor 120 instead. Debug- 
ging microprocessor 120 controls the execution of the 
user programs, accesses data in memory 40, and 
accesses I/O 50 by executing the monitor program 
stored in monitor program memory 1 30 on the debugging 
tool. Moreover, debugging microprocessor 120 executes 
programs stored in memory 40 on the user target system 
just as though the microprocessor 10 were executing 
them. Moreover, debugging tool 1 1 0 has a trace memory 
140. and can trace the state of the processor bus of 
debugging microprocessor 120. Debugging microproc- 
essor 1 10 outputs the trace information that is not avail- 
able from microprocessor 10. By doing so. some of the 
internal state of the processor that cannot be traced from 
the processor bus alone can be traced. 

Fig. 4 shows example 4 of the prior art which is a 
debugging system that is generally called a pre-proces- 
sor. By connecting the probe of a logic analyser 150 to 
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Problems the Present Invention Seeks to Solve 



In example 1 of the prior art. since the monitor pro- 
gram runs on the user memory, if an operation of the 
memory system of the user's target system is not com- 
plete, there are cases in which the monitor itself does not 
15 operate in a stable manner. Moreover, if there is no room 
left in the memory of the target system, the address 
space to be occupied by the monitor may not be availa- 
ble. Furthermore, since some of the user interrupt must 
be used for the entry into the' monitor mode, debugging 
20 is sometimes impossible, depending on the kind of pro- 
gram. Moreover, it is necessary to provide circuits such 
as a serial interface circuit in the target system that may 
not be used after the debugging. Also, since no 
resources for debugging, such as hardware break points 
25 are provided, the debugging functions are poor, and 
traces cannot be obtained. 

In example 2 of the prior art, since a sequencer is 
incorporated in the microprocessor, and the sequencer 
accesses the registers, the logic circuits for connection 
30 with the debugging tool become complex, and the sur- 
face area they require on the chip becomes large. More- 
over, when additional registers or the like are provided, 
the sequencer must be updated. Furthermore, traces 
cannot be obtained in this prior art example. 
35 in example 3 of the prior art, since the debugging 
tool is connected to all of the pins of the microprocessor 
on the user target, the probe becomes expensive, and 
the contact of the probe is often unstable. Moreover, 
when switching accesses between the memory on the 
40 target and the monitor memory in the debugging tool, the 
buses must be switched rapidly; therefore, it is difficult to 
implement with processors running at a high operating 
frequency. If there are derivative microprocessors, 
because their packages, pin counts and pin assignment 
45 are different, though essentially the same debugging tool 
can be used, different debugging tools must be prepared 
with probes for the respective derivative microproces- 
sors, Moreover, connecting the probe has an influence 
on the signals used in the user target, which may some- 
so times make the operation of the user target itself unsta- 
ble. 

Though example 4 of the prior art is effective with 
respect to tracing, even with high-frequency processors, 
it capnot perform tracing with respect to processors with 
55 internal cache memories while the cache is being hit. 
Moreover, with respect to the processors with internal 
queues, it is not possible to determine whether fetched 
instructions are executed or not. Furthermore, there is 
no function for controlling the execution of the user pro- 
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gram, and it is not possible to read the contents of the 
user memory or the I/O. 

Summary of the Invention 

In order to solve the problems of example 1 of the 
prior art, the monitor memory is provided in the debug- 
ging tool, the monitor program is operated by using sig- 
nals dedicated to the debugging tool, an interrupt 
dedicated to the debugging tool is prepared, and a hard- 
ware break function is incorporated in the microproces- 
sor. In order to solve the problems of example 2 of the 
prior art, the registers, the user memory, and the I/O are 
accessed by using a monitor program. In order to solve 
the problems of example 3 of the prior art, the logic cir- 
cuits for running monitor programs in the monitor mem- 
ory in the debugging tool, the logic circuits for performing 
execution control including hardware break points, and 
the logic circuits for outputting the PC information of the 
executed instructions are incorporated in the microproc- 
essor. Moreover, pins dedicated to connection with the 
debugging tool are provided in the microprocessor, and 
only these pins are connected with the debugging tool. 
Further, a function is added which lowers the clock fre- 
quency only during the execution of the monitor program. 
In order to solve the problems of example 4 of the prior 
art. the logic circuit for executing a monitor program on 
the monitor memory in the debugging tool, the logic cir- 
cuit for execution control including hardware break 
points, and the logic circuit for outputting PC information 
of the executed instructions are incorporated into the 
microprocessor. 

Brief Explan ation of the Drawings 

Fig. 1 : Diagram showing the structure of example 1 
of the prior art. 

Fig. 2: Diagram showing the structure of example 2 
of the prior art. 

Fig. 3: Diagram showing the structure of example 3 
of the prior art. 

Fig. 4: Diagram showing the structure of example 4 
of the prior art. 

Fig. 5: Diagram showing the structure of an embod- 
iment of the present invention. 

Fig. 6: Diagram showing the structure of the debug- 
ging module of an embodiment of the present invention. 

Fig. 7: Diagram showing the structure of the debug- 
ging tool of an embodiment of the present invention. 

Fig. 8: Diagram showing an outline of circuits related 
to the serial monitor bus of an embodiment of the present 
invention. 

Fig. 9: Timing chart of the write bus operation of the , 
serial monitor bus in an embodiment of the present 
invention. 

Fig. 10: Timing chart of the write bus operation of 
the serial monitor bus in an embodiment of the present 
invention. 



Fig. 1 1 : Timing chart showing an example of the PC 
trace output of a branch instruction in an embodiment of 
the present invention. 

Fig. 12: Timing chart showing an example of the PC 
trace output of an indirect jump instruction in an embod- 
iment of the present invention. 

Fig. 13: Timing chart showing an example of the PC 
trace output of an exception and indirect jump instruction 
in an embodiment of the present invention. 

Fig. 1 4: Timing chart showing an example of the out- 
put timing of the PCST[2:0] when a debug exception 
occurs in an embodiment of the present invention. 

Fig. 15: Timing chart showing the output timing of 
the PCST[2:0] in a case in which a target PC is output 
when a debug exception occurs in an embodiment of the 
present invention. 

Fig. 16: Timing chart showing the output timing of 
the PCST[2:0] when there is a return from the debugging 
mode in an embodiment of the present invention. 

Fig. 17: Timing chart of an example of the occur- 
rence of a trace trigger during the successive execution 
of ordinary instructions. 

Fig. 18: Timing chart of an example of a case in 
which a trace trigger has occurred during the execution 
of an exception-occurring instruction. 

Fig. 19: Timing chart of an example of a case in 
which a trace trigger occurred during the execution of an 
indirect jump instruction. 

Fig. 20: Diagram showing the structure of the trace 
memory interface and the trace memory in the debug- 
ging tool 60. 

Fig. 21 : Diagram showing the structure of the power 
supply part of the debugging module. 

Fig. 22: Diagram showing the structure of the initial- 
ization circuit of the debugging module. 

Explanation of Symbols: 

1 0: microprocessor 

1 5: internal debugging interface 

1 6: internal processor bus 

20: processor core 

30: debugging module 

31 : instruction/data address break circuit 

32: PC trace circuit 

33: processor bus break circuit 

34: serial monitor bus circuit 

35: register circuit 

36: external interface circuit 

37: frequency-dividing circuit 

38: power source switch 

40: memory 

50: I/O 

60: debugging tool 

70: user target system 

71: externa! debugging interface 

90: processor bus 

342: serial output circuit A 

343: serial input circuit A 
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630; 

640 

650 

651 
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661 

662 

663 

664: 

665: 

667 

670 

680 

690 



communication interface 
controller 
monitor memory 
monitor memory interface 
serial input circuit B 
serial output circuit B 
trace memory interface 
trace memory control circuit 
trace address counter 
trace data register 
trace trigger decoder 
controller address register 
controller data register 
trace memory 
run controller 
target interface 



Detailed D escription of the Invention 

The present invention will be explained below with 
respect to embodiments in which the present invention 
is applied to a microprocessor incorporating a processor 
core with 32-bit addresses and a 32-bit data bus. The 
asterisks (*) added to signal names in the figures and 
during the explanation below indicate that these signals 
are negative logic. 

Overall Explanation of Debugging System 

Fig. 5 shows a structural diagram of the debugging 
system of an embodiment of the present invention. The 
debugging system comprises a user target system 70 
and a debugging tool 60. User target system 70 is con- 
structed with a microprocessor 10 that incorporates a 
debugging function, a memory 40, and an I/O 50. Micro- 
processor 1 0 is constructed with a processor core 20 and 
a debugging module 30. Processor core 20 accesses 
memory 40 and I/O 50 through processor bus 20 and 
executes programs. Processor core 20 is further con- 
nected to debugging module 30 via an internal debug- 
ging interface 15 and an internal processor bus 16. 
Debugging module 30 is connected to debugging tool 60 
via an external debugging interface 71. 

Explanati on of the Execution Modes 

The debugging system has two execution modes: a 
debugging mode in which the microprocessor executes 
the monitor program, and a normal mode in which the 
microprocessor executes the user program. 

Explanation of the De hugging Mnrte 

If a debug exception or a debug reset occurs in proc- 
essor core 20, a jump to the vector address of the debug 
exception or reset is executed and the debugging mode 
is entered. The memories corresponding. to these vector 
addresses are located in debugging tool 60. Processor 
core 20 executes the monitor program on debugging tool 



60 through debugging module 30. The monitor program 
implements the execution control functions, such as the 
reading and writing of memory, I/O, and registers, the 
setting of hardware break points, the indication of the 
5 execution start address of the user program, etc. Execu- 
tion of the return to the normal mode instruction by proc- 
essor core 20 causes return to the normal mode to start 
or re-start the execution of the user program. 

10 Explanation of the Normg l KAnrta 



In the normal mode, the debugging system executes 
the user program. In the normal mode, the PC (program 
counter) information is output to an external debugging 
interface 71. The debugging system requests a debug 
exception or debug reset to processor core 20, by means 
of hardware break, software break, debug interrupt, 
debug reset etc., and passes control, to the debugging 
mode. 
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20 



Summary Explanatio n of the Debugging Module Func- 
tions 
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Below, explanation will be given on the serial monitor 
bus function which is operative during the debugging 
mode, and on the PC trace function, trace trigger func- 
tions, hardware break functions, software breakf unction, 
debug interrupt, debug reset, and masking function 
which are operative in the normal mode. 

Explanati on of the Serial Monitor Bus Function 

When processor core 20 accesses the address 
region dedicated to the monitor, the serial monitor bus 
function is executed by accessing the monitor memory 
in debugging tool 60 through a serial transmission path 
by means of the pins dedicated to debugging. When a 
region outside the memory dedicated to the monitor is 
accessed, access through the ordinary processor bus is 
performed. By this means, the monitor can also access 
the memory and I/O on the user target system. Though 
thebit width of the serial monitor bus is 1 bit in the embod- 
iments below, if more microprocessor pins are available 
for this bus, one can also make it multiple-bit wide. 

Explanation of the PC Trace Function 

The PC trace function traces the program counter 
(PC) values while processor core 20 is executing a user 
program. This is implemented by outputting the PC trace 
information to internal debugging interface 15 when 
processor core 20 is executing the user program from 
memory 40, having debugging module 30 obtain and 
process it, and then outputting it to the debugging tool 
via the external debugging interface. 
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Explanation of the Trace Trigger Functions 

There are three kinds of trace trigger functions: the 
instruction address trace trigger,. the data address break 
and the processor bus trace trigger. The instruction s t ♦ 
address trace trigger function is implemented by com- 
paring the value of the instruction execution address that 
processor core 20 outputs, to the internal debugging 
interface with the value of the address that has been set 
in the register in debugging module 30. When they 10 
match, debugging tool 60 is informed via external debug- 
ging interface 71 that a trace trigger has occurred. The 
data address trace trigger function is implemented by 
comparing the value of the data access address that 
processor core 20 outputs to the internal debugging is 
interface, with the value of the address that has been set 
in the register in debugging module 30. When they 
match, debugging tool 60 is informed through external 
debugging interface 71 that a trace trigger has occurred. 
The processor bus trace trigger function is implemented 20 
by comparing the value of the data access address and 
the data that processor core 20 outputs to the internal 
debugging interface, with the value of the address and 
data that has been set in the register in the debugging 
module 30. When they match, debugging tool 60 is 25 
informed through external debugging interface 71 that a 
trace trigger has occurred. 

Explanation of the Hardware Break Function 

30 

There are three kinds of hardware break functions: 
an instruction address break, a data address break, and 
a processor bus break. The instruction address break 
function is implemented by comparing the value of the 
instruction execution address processor core 20 outputs 35 
to the internal debugging interface, with the value of the 
address that has been set in the register in the debugging 
module 30. When they match, a debug exception is dis- 
patched to processor core 20. The data address break 
function is implemented by comparing the value of the *o 
data access address processor core 20 outputs to the 
internal debugging interface, with the value of the 
address which has been set in the register in debugging 
module 30. When they match, a debug exception is dis- 
patched to processor core 20. The processor bus break 45 
function is implemented by comparing the values of the 
data access address and the data processor core 20 out- 
puts to the internal debugging interface, with the values 
of the address and data that have been set in the register 
in debugging module 30. When they match, a debug so 
interrupt request is dispatched to processor core, 20. 

Explanation of the Software Break Function 

The software break function causes a debug excep- ss 
tion wherein processor core 20 executes a software 
break instruction. It causes a transfer to the debug mode. 



Explanation of the Debug Interrupt Function 

In the debug interrupt function, processor 20 causes 
a debug interrupt by asserting a debug interrupt signal. 
It causes a transfer to the debug mode. 

Explanation of the Debug Reset Function 

In the debug reset function, processor 20 causes a 
debug reset by asserting a debug reset signal. It initial- 
izes the internal states of processor 20 and debugging 
module 30, sets processor core 20 to be in the debug 
mode, and causes execution of the program to start from 
the vector address for the debug reset. 

Explanation of the Mas king Function 

The masking function, according to its setting, 
masks the user interrupt during the normal mode or 
masks the user reset during the debug mode. 

Detailed Explanation of the Overall Construction of the 
Debugging Module 

Debugging module 30 will now be explained in 
detail. Fig. 6 shows the internal blocks of debugging 
module 30. Debugging module 30 contains an instruc- 
tion/data address break circuit 31 . a PC trace circuit 32. 
a processor bus break circuit 33, a serial monitor bus 
circuit 34, a register circuit 35, an external interface cir- 
cuit 36, and a frequency dividing circuit 37. 

PC trace circuit 32 is connected to processor core 
20 by internal debugging interface 15. The PC informa- 
tion of the executed instructions, output from processor 
20. is input, the information is processed, and the result 
is output to the external interface circuit 36. 

Instruction/data address break circuit 31 is con- 
nected to processor core 20 by internal debugging inter- 
face 15. In case circuit 31 inputs the instruction address 
output from processor 20 and its value matches the 
instruction address set in register circuit 35, the circuit 
requests an instruction address break exception to the 
processor core 20, if the use of instruction address 
breaks has been enabled. Then, if the use of trace trig- 
gers has been enabled, the occurrence of the trigger is 
informed to PC trace circuit 32. 

In case the circuit inputs the data address output 
from processor core 20 and the value matches the data 
address which has been set in register circuit 35, a data 
address break exception request is dispatched to proc- 
essor core 20, if the use of data address breaks has been 
enabled. Then, if the use of trace triggers has been ena- 
bled, the occurrence of the trigger is informed to the PC 
trace circuit 32. The use of a break or a trace trigger is 
enabled by the value of the corresponding bit of the cor- 
responding register in register circuit 35. 

Processor bus break circuit 33 is connected to proc- 
essor core 20 through internal processor bus 16. Each 
bit of data can be masked. This circuit monitors the bus 
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cycles on the processor bus, and if the address and data 
set in register circuit 35 matches the address and data 
occurring during the bus cycle, it will dispatch an excep- 
tion request to the processor core. Then, if the use of 
trace triggers has been enabled, the occurrence of the 5 
trigger is informed to PC trace circuit 32. 

Serial monitor bus circuit 34 is connected to proces- 
sor core 20 through an internal processor bus 1 6. When 
the processor core executes a monitor program on 
debugging tool 60, the circuit converts the data in parallel 1 o 
format into serial format, or converts the data in serial 
format into to parallel format for interfacing therebe- 
tween. 

Register circuit 35 contains control registers which 
control the functions of the debugging module. An is 
address is allocated to each register. They are con- 
nected to processor core 20 via internal processor bus 
16 and internal debugging interface 15 so that the con- 
tents of the control registers can be read or written by 
running the monitor program. Moreover, the contents of 20 
the control register are output to each circuit in debug- 
ging module 30 and to processor core 20 to control the 
debugging function. 

External interface circuit 36 controls PC trace circuit 
32 in debugging module 30, serial monitor bus circuit 34, 25 
and the interface of processor core 20 and debugging 
tool 60. The masking function is also implemented within 
external interface circuit 36. 

Frequency dividing circuit 37 divides the frequency 
of the clock signal CLK. The serial monitor bus circuit is 30 
operated by the frequency-divided clock CLK 2. 



PC information being sent from the microprocessor on 
the user target is not obstructed. 

Run controller 680 inputs the user reset signal 
RESET* which is fed from user target system 70 and volt- 
age VDD of the power source line of the user system. By 
giving the debug interrupt signal DINT* and the debug 
reset signal DRESET* to the user target system, it 
resets, stops, or executes the user program. 

Target interface 690 consists of a circuit for protect- 
ing user target system 70 and debugging tool 60 when 
the power is turned on, and a circuit which regulates the 
input/output voltage according to the power source volt- 
age of target user system 70. 

Interface Signals betwe en the Debugging Tool anri th* 
Microprocessor 



There are in total twenty lines for the interface sig- 
nals between the debugging tool and the microproces- 
sor. The input/output designations show the directions 
when seen from the microprocessor side. The following 
eight lines are for the external, debugging interface sig- 
nals between the debugging modules 30 and the debug- 
ging tool 60: 

1. DCLK: output 

2. DRESET : input 

3-5. PCST(2:0) : output \ 

6. SDAO/TPC : output 

7. SDI/DINT : input 

8. DBGE : input 



Detailed Explanation of the Overall Construction nf thg 
Debugging Tnnl 



Fig. 7 shows the overall construction of the debug- 
ging tool. Debugging tool 60 contains communication 
interface 620, controller 630, monitor memory 640, mon- 
itor memory interface 650 t trace memory interface 660, 
trace memory 670, run controller 680, and target inter- 
face 690. 

Communication interface 620 performs communica- 
tions with the host computer. Controller 630 analyzes 
commands sent from the host computer via communica- 
tion interface 620, executes them, and returns the 
results. Monitor memory 640 is the memory for storing 
and executing the monitor program. Monitor memory 
interface 650 converts the serial signals from the user 
target system 70 into parailel signals accessible to mon- 
itor memory 640, and also arbitrates the access requests 
from controller 630 and the microprocessor on the user 
target. 

Trace memory 670 is the memory for storing the PC 
information which is sent from microprocessor 10 on 
user target system 70. Trace memory interface 660 
stores in trace memory 670, the PC information sent 
from microprocessor 1 0 on the user target system. More- 
over, when there is an access request from controller 
630, it arbitrates this request so that the storage of the 



The following signals . are also connected to 
debugging tool 60, although they are not dedicated to 
35 the debugging tool. 

9. RESET : output 

10. VDD : output 

40 Ten ground lines are also connected. 
11-20. QND : ground 

(1 ) DCLK (Debug clock) : output terminal; 

45 

This is the clock output to debug tool 60. The timing 
of all of the serial monitor bus and the PC trace interface 
signals is defined by this debug clock DCLK. When the 
serial monitor bus is functioning, DCLK is the clock 
so obtained by frequency-dividing the operating clock of the 
processor core 20. 

(2) DRESET* (Debug reset) : input terminal (terminal 
with pull-up); 



55 



Debug reset input A low-active signal. When 
DRESET* is asserted, the ICE module is initialized (not 
related to DBGE). When debugging tool 60 is not used, 
this terminal should not be connected. 
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(3) PCST (2:0) (PC trace status) : output terminal; 

These terminals output the PC trace status informa- 
tion and the serial monitor bus mode given below. The 
table below shows the meanings of the 3-bit codes output 
by the PCST 
1 1 1 (STL) : pipeline stall 
110 (JMP) : branch/jump taken (with PC output) 
101 (BRT) : branch/jump taken (without PC output) 
100 (EXP) : exception occurred (with an exception vector 
code output) 

011 (SEQ) : sequential execution (indicating that 1 
instruction was executed) 

010 (TST) : trace trigger output during pipeline stall 

001 (TSQ) : trace trigger output during execution 

000 (DBM) : debugging mode (0: low level, 1 : high level) 

Table 1 

(4) DBGE* (Debugger Enable) : input terminal (terminal 
with pull-up); 

This terminal indicates whether the debugging tool 
60 is connected or not. If debugging tool 60 is not con- 
nected externally, it becomes high-level because of the 
pull-up. Since debugging tool 60 side is made low-level, 
connecting the debugging tool makes it low-level. 

When debugging tool 60 is not connected (when the 
DBGE* signal is high-level), the debug exception vector 
address of processor core 20 becomes a region which 
is released to the user, allowing the control to be trans- 
ferred to a monitor prepared by the user on the debug 
exception. Moreover, the user reset is disabled (which 
initializes the debugging module function to disable the 
debugging functions), except for the hardware break 
function, reducing power consumption of the microproc- 
essor. Moreover, all the output signals (SDAO/TPC, 
DCLK, PCST[2:0]) exhibit a high-impedance state. 

When debugging tool 60 is connected, the debug 
exception vector address of processor core 20 becomes 
the monitor-dedicated region which is not released to the 
user. At this time, the user reset does not initialize the 
debugging module, which allows the debugging func- 
tions to be utilized, even immediately after user reset 
That is, the present invention satisfies the request to 
observe the behavior of the user target system immedi- 
ately after the user reset. 

(5) SDAO/TP (Serial data and address output/target PC) : 
output terminal; 

When the microprocessor is executing a monitor 
program (hereinafter referred to as the debugging 
mode), this terminal functions as the terminal SDAO 
(Serial Data and Address Output) which serially outputs 
data/address. When the microprocessor is executing a 
user program (hereinafter referred to as the normal 
mode), it functions as the terminal TPC (Target PC) 
which serially outputs the target PC. 



Function as SDAO 

This is the signal terminal which outputs data, 
address, read/write and byte enable signals, serially, one 
5 % bit at a time. It outputs a start bat before the beginning of 
1 each bus cycle (that is. it outputs the low level for one 
clock period). Its output order on reading is: a start bit 
(low level), A2-A19, RD, WR. BE0-BE3; on writing, the 
output order is: a start bit (low level), A2-A19. RD, WR. 
10 BE0-BE3. D0-D31. 

Function as TPC 

This is the signal for outputting the target addresses 
is of a branch/jump instruction and a vector number of 
exceptions/interrupt. The target address is output in 
sequence from the low address A[2] to the high address 
A[31]. 

20 (6) SDI/DINT* (Serial data input/debug interrupt) : input 
terminal (with pull-up); 

In the debugging mode, this terminal acts as the 
serial data input terminal SDI (Serial data input); in the 
25 normal mode, its acts as the debug interrupt terminal 
DINT* (Debug interrupt). 

Function as SDI 

30 Data input signal terminal. On reading, when a start 
bit (low-level) is input from outside, data input will start 
from the next clock. On writing, when a low level is input, 
the bus cycle completes. The order of input on reading 
is: a start bit (low-level), D[0]-D[31]. On writing, only an 

35 end bit (low-level) is input. 

Function as DINT* 

Debug interrupt input from debugging tool 60. When 
40 debugging tool 60 is not used, this terminal should be of 
no connection. 

(7) RESET* (Reset) : output terminal; 

45 User reset terminal. By connecting this signal to the 
debugging tool, for example, when there is no response 
from the debugging module 30. it can determine whether 
this is due to a user reset signal or not. Causing the 
debug reset immediately after the user reset can be done 

so by keeping D RESET* active until after RESET* signal 
goes high. 

(8) VDD (VDD) : output terminal; 

55 Power source line of the user target system. By 
inputting this into debugging tool 60, debugging tool 60 
can find out the power source voltage of user target sys^ 
tern 70. This allows an alteration of the threshold value 
of the input waveform and the voltage level of the output 
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waveform in compliance with the power source voltage 
of the user target system. Moreover, when it is deter- 
mined that the power source of user target system 70 is 
not on, the output devices of debugging tool 60 is made 
high-impedance to protecting them. 5 

(9) GND (GND) 

In order to match the ground levels of debugging tool 
60 and user target system 70, ten ground lines are con- io 
nected. They are interleaved with the above-mentioned 
signals (1 ) through (8) in the transmission cable between 
debugging tool 60 and user target system 70 so as to 
reduce the cross-talk among these signals. 

75 

Detailed Explanation of the Serial Monitor Bus Circuit 

The operation of serial monitor bus circuit 34 of Fig. 
6 will be explained. 



Outline of the Function of the Serial Monitor Bus 



20 



During the debug mode, when processor core 20 
accesses the monitor-dedicated region, the memory on 
debugging tool 60 is accessed through the serial monitor 25 
bus circuit 34. In write operations using the serial monitor 
bus, serial monitor bus circuit 34 outputs the address, 
the bus control signals, and the data to the SDAO signal, 
serially 1 bit at a time. In read operations, it outputs the 
address and the bus control signals serially 1 bit at a 30 
time. In read operations, it outputs the address and the 
bus control signals to the SDAO signal and inputs data 
from the SDI signal serially 1 bit at a time. 

The serial monitor bus is operated by the clock CLK 
2 which frequency-divides the operating clock CLK of the 35 
processor core 20. 18 bits A[19:2] of the address signal 
of the processor core are output to the serial monitor bus 
which enables to access into a 1 Mbyte memory space. 
Since the byte enable signal BE[3:0] of the processor 
core 20 is output to the serial monitor bus, byte, half- 40 
word, and 3-byte accesses are also possible. However, 
in the serial monitor bus, even in the cases of byte, half- 
word or 3-byte access, 32-bit wide data is transmitted. 

When one byte, half-word or three bytes are written, 
the data portion corresponding to the byte position where 45 
BE[3:0] is inactive is undefined. On reading, the data at 
the inactive byte positions are ignored by the processor 
core 20, and are not read. 

In the normal mode, writing to the regions dedicated 
to the monitor is ignored; on reading, the result is unde- so 
fined. When this kind of write access has occurred, serial 
monitor bus circuit 34 sends an acknowledge signal, 
showing completion of the bus operation, to processor 
core 20, and then the bus operation is completed. 

55 



Detailed Explanation of Method for Transmitting the Sig- 
nals of the Serial Monitor Bus 

Fig. 8 shows an block diagram of the serial monitor 
bus. With reference to Fig. 8, the procedure of transmis- 
sion of signals will be explained. 

In Case the Processor Core 20 Performs a Memory 
Read 

(1) The parallel-format address, read signal, and 
byte enable output from the processor core 20 are 
converted into serial format by serial output circuit 
A342 and output from the. SDAO. 

(2) The serial monitor input circuit B651 in debug- 
ging tool 60 inputs them and converts them into par- 
allel format and outputs the parallel format to monitor 
memory 640. 

(3) The data in parallel forrhat output from the mem- 
ory are converted into serial format by serial output 
circuit B652 and are output through the SDI. 

(4) The serial input circuit A343 in debugging module 
30 converts them into parallel format and outputs 
them to processor core 20. 

(5) The processor core 20 reads the data in parallel 
format. 

In case the Processor core 20 Perfor ms a Memory Write 

(1) The address, write signal, byte enable and data, 
in parallel format as output from processor core 20, 
are converted into serial format by serial output cir- 
cuit A342 and output from the SDAO. 

(2) Serial input circuit B651 in debugging tool 60 
inputs and converts them into parallel format and 
outputs the signals to monitor memory 640. 

(3) When the writing to monitor memory 640 is com- 
pleted, serial output circuit B652 outputs low level 
for one clock to the SDI. r 

(4) Serial input circuit A343 in microprocessor 10 in 
user target system 70, when this low level has been 
input, notifies processor core 20 that the write cycle 
has been completed. 

(5) The processor core 20 ends the write cycle. 



Detailed Explanation of the Timing of the Serial Monitor 
Bus Operation 



The serial monitor bus operation will be explained in 
detail below, using timing charts. 

Read bus operation of serial monitor bus 

Fig. 9 shows the timing chart of the read bus oper- 
ation of the serial monitor bus. 

(1 ) Processor core 20 starts a read bus operation to 
the monitor-dedicated region (cycle 1). Processor 
core 20 outputs the address to be accessed to the 
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processor bus in parallel format, asserts a read sig- 
nal, and asserts the byte enable signals at the byte 
positions to be read. 

(2) Serial monitor bus circuit 34 outputs low level for 
one clock of the CLK 2, which is the frequency- s % 
divided clock of the core clock CLK, to the SDAO 1 
signal when the start of the read bus operation to 

the monitor region is recognized (cycle 2). 

(3) Serial monitor bus circuit 34 outputs the address 
A[2]-A[19], a high level (indicating a read) and the io 
byte enable signals BE[0]*-BE[3]* which have been 
output in the read bus operation of processor core 

20, to the SDAO signal in this order, each taking one 
clock of the CLK2 signal (cycles 3-25). 

(4) Monitor memory interface 650 in debugging tool is 
60 inputs the address A[2]-A[1 9], the high level (indi- 
cating a read) and the byte enable signals BE[0]*- 
BE[3]* which have been output to the SDAO signal, 

in this order, one bit at every clock of DCLK. The 
address and byte enable signals are then converted 20 
into parallel format and output to monitor memory 
640. 

(5) Monitor memory interface 650 converts the par- 
allel-format data output from monitor memory 640 
into serial format. Before the data are output, a low 
level is output to the SDI signal for one clock (cycle 
n). Following this, the data are output in sequence 
from D[0] to D[31], one bit at a time, synchronized 
with DCLK (cycles n+1 to n+32). 

(6) Serial monitor bus circuit 34, when a low level is 
detected in the SDI (cycle n), reads in the data D[0]- 
D[31] from the next cycle, for each clock of DCLK 
(cycles n+1 to n+32). 

(7) Serial monitor bus circuit 34 asserts a response 
signal of the read bus of the processor core 20 and 
outputs the 32 bits of data which were read to the 
processor bus in parallel format (cycle n+33). 

(8) Processor core 20 reads the data on the proces- 
sor bus and completes the read bus operation. 

Write Bus Operation of the Serial Monitor Bus 

Fig. 10 shows the timing chart of the write bus oper- 
ation of the serial monitor bus. 

(1) Processor core 20 starts a write bus operation to 
the monitor-dedicated region (cycle 1). Processor 
core 20 outputs the address to be accessed to the 
processor bus and asserts a write signal. The byte 
enable signal of the position of the byte to be written so 
is asserted. 

(2) Serial monitor bus circuit 34 outputs a low level 
for one clock of the CLK 2 which is the frequency- 
divided dock of the core clock CLK when the start 

of the write bus operation to the monitor region is ss 
recognized (cycle 2). 

(3) Serial monitor bus circuit 34 outputs the address 
A[2]-A[19], a low level'tindicating a read), the byte 
enable signals BE[0]*-BE[3]*, and the write data 
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35 



40 



45 



DOUTfl)]-DOUT[31] which have been output in the 
write bus operation of the processor core 2, in this 
order, to the SDAO signal, one bit at every clock of 
CLK2 signal (cycles 3-57). 

(4) Monitor memory interface 650 in debugging tool 
60 inputs the address A[2]-A[19] (the high level indi- 
cating a read), the byte enable signals BE[0]*- 
BE[3]*, and the write data DOUT[0]-DOUT[31], 
which have been output to the SDAO signal, in this 
order, one bit at every clock of DCLK. The address, 
byte enable signals and write data are then con- 
verted into parallel format and output to monitor 
memory 640. 

(5) When monitor memory interface 650 has com- 
pleted the writing to monitor memory 640, a low level 
is output to the SDI signal for one clock (cycle n). 

(6) Serial monitor bus circuit 34, when a low level is 
detected in the SDI, asserts a write bus response 
signal to processor core 20 (cycle n+1). 

(7) Processor core 20 completes the write bus oper- 
ation. 

PC traQQ Cirquit 

The terms "indirect jump," "direct jump," and 
"branch" will be defined below. 

Indirect jump: A jump in which the jump address can- 
not be determined in the instruction itself, such as a jump 
to an address stored in a register. 

Direct jump: A jump in which the jump address is 
determined by an address at which the instruction itself 
is located and the instruction code. 

Branch: A jump in which the branch address can be 
determined by the sum of the address at which the 
instruction itself is located and part of portion of the 
instruction code. In a branch, whether the jump is actu- 
ally taken or not is determined by conditions. If the jump 
is actually taken, it is called "branch taken"; if it is not 
taken, it is called "branch not taken." 

PC traces include the following two kinds of trace 
modes. 

Real-time trace mode: In this mode, the execution 
of the processor core 20 is always performed in real time, 
but when the next indirect jump occurs during the target 
PC output of the previous indirect jump, outputting of the 
target PC of the indirect jump occurred first is aborted, 
and outputting of the new target PC is started. 

Non-real-time trace mode: In this mode, when adja- 
cent indirect jumps occur as described above, the pipe- 
line processing of the processor core 20 is halted until 
the target PC of the previously produced indirect jump is 
completely output. In this way, the real time execution of 
the processor core 20 is impaired, but the target PC of 
the indirect jump is always completely output. 

The PC trace circuit 32 inputs the following signals 
from the processor core 20. 

Debugging mode signal: This signal indicates 
whether the processor core 20 is in the debugging or the 
normal mode. 
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Pipeline execution signal: This signal indicates that 
an instruction has been executed. 

30-bit target PC signal [31:0]: This signal indicates 
target address of branch or jump instruction or a vector 
address of an exception. It is effective when the following 
indirect jump signal, direct jump signal, branch taken sig- 
nal, or exception occurrence signal is asserted. 

Indirect jump signal: This signal indicates that an 
indirect jump has been executed. 

Direct jump signal: This signal indicates that a direct 
jump has been executed. 

Branch taken signal: This signal indicates that an 
actually taken branch instruction has been executed. 

Exception occurrence signal: This signal indicates 
that an exception has occurred. 

The PC trace circuit 32 outputs the following signals 
to the processor core 20 for completely performing the 
PC trace. 

Pipeline stall request signal: When in non-real-time 
trace mode, in which target PC outputs are performed 
completely, this signal stalls the pipeline of processor 
core 20. PC trace circuit 32 asserts this signal and stalls 
the pipeline of processor core 20 when a subsequent 
indirect jump occurs while an indirect jump target PC is 
being output. When the target PC during the output is 
completely output, this signal is negated and the pipeline 
processing of the processor core 20 resumes. 

PC trace circuit 32 inputs trigger request signals 
from instruction/data address break circuit 31 and proc- 
essor break circuit 33. It also inputs the status of the bit 
which switches the trace mode, allocated to a register in 
register circuit 35. 

PC trace circuit 32 converts the PC trace information 
which processor core 20 outputs during normal mode 
operation to a 1 -bit PC output (TPC signal) and 3-bit sta- 
tus information (PCST[2:0] signals) and outputs them to 
debugging tool 60. The PCST[2:0] and TCP signals will 
be explained below. 

PCST[2:0]: At each clock, the execution status of the 
instructions is output to PCSTI2:0]. In the following expla- 
nation, "0" represents the low level and "1 M the high level. 

1 1 1 (STL) : pipeline stall: This indicates that the exe- 
cution of an instruction was not completed, in a status in 
which there is no trace trigger output. 

110 (JMP): branch/jump taken (PC output exists): 
This indicates that a branch instruction is taken or a jump 
instruction is performed, and output of the target address 
(address of branch or jump) to the TPC signal was 
started. 

101 (BRT): branch/jump taken (no PC output exists): 
This indicates that a branch instruction is taken or a jump 
instruction is performed, but there is no output of the tar- 
get address (address of branch or jump) to the TPC sig- 
nal. 

100 (EXP): exception occurred (code output of 
exception vector exists): This indicates that exception 
has occurred. It simultaneously indicates that code out- 
put of exception vector to TPC signal was started. The 
code is of 3 bits and is output to the TPC signal jn the 
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Kind of exception 


Vector address 


Code 




Reset, Nmi 


BFCO_0000 (100) 


4 




UTLB(BEV=0) 


8000_0000 (000) 


0 


10 


UTLB(BEV=1) 


BFC0_0100 (110) 


6 


Other (BEV=0) 


8000.10080 (001) 


1 




Other (BEV=1) 


BFCO_0180 (111) 


7 



Here, BEV is one bit in the register in the register 
circuit 35; the vector address of the exception handling 
can be changed by its value. 

01 1 (SEQ): sequential execution y (indicating that an 
instruction has been executed): This indicates that an 
instruction has been executed' wherein that instruction is 
other than a taken jump or branch (JMP, BRT) in a state 
in which there is no trace trigger output request (TSQ). 
This code is also output when a branch has not been 
taken. 

010 (TST): trace trigger is output during pipeiine 
stall: This indicates that an instruction address trace trig- 
ger or processor bus trace trigger occurred in a clock at 
which no instruction was completed. 

001 (TSQ): Trace trigger is output during execution: 
This indicates that an instruction address trace trigger or 
processor bus trace trigger occurred in a clock at which 
no instruction was completed. 

000 (DBM): Debugging mode: This code is not out- 
put in the normal mode. 

TPC: This is the signal for outputting the target 
address of a branch or jump instruction. The output of 
the target address is started from the clock in which the 
110 (JMP) was output to the PCST[2:0]. The target 
address is output one bit at every clock from the low A(2). 

The 3-bit code of the exception vector is output to 
the PCST[2:0] from the clock in which the 1 0O(EXP) was 
output. The code is output one bit at every clock from the 
lowcode(O). 

Since the target address is output in a 1 -bit serial 
manner to the TPC signal, the next branch or jump 
instruction or exception sometimes occurs while the pre- 
vious branch or jump instruction is being output to the 
TPC signal. The priority of thetarget address output to 
the TPC in this case is defined as follows. 

(1) When the trace mode is the real-time mode, if a 
new indirect jump occurs during a target PC output. 
Jthe previous target PC output is aborted and the tar- 

* get PC output of the new indirect jump is always 
started. 

(2) When the trace mode is the non-real-time mode, 
if a new indirect jump occurs during a target PC out- 
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put the pipeline processing of the processor core is 
halted until the previous target PC output is com- 
pleted. The processor core pipeline processing is 
restarted and the output of the target PC of the new 
indirect jump is started after that target PC output is 5 
completed. ' 

(3) When an exception has occurred during a target 
PC output, the vector number (3 bits) of the excep- 
tion is always output, after which the interrupted PC 10 
output is restarted. 

(4) When a new direct jump or branch has be taken 
during a target PC output, the output of the target 
address of this direct jump or branch is not per- is 
formed. With respect to a direct jump or branch, its 
target PC is output only when another target PC is 
not being output when it is taken. 

In the case of a direct jump or branch, even if the 20 
target address is not output, if the address of that instruc- 
tion is known, the address of the jump or branch desti- 
nation can be determined by referring to the code of that 
instruction stored in memory. The address of that instruc- 
tion is determined by the clock count between the exe- 2s 
cution of that instruction and the previously occurred 
direct jump or branch. 

Examples of PC trace outputs will now be explained 
with reference to the drawings. 

30 

(Example 1) PC trace of branch instruction 

Fig. 1 1 shows an example of a PC trace output of a 
branch instruction. When the first branch instruction beq 
is taken, no target PC is being output to TPC. Therefore, 3s 
the JMP code is output to PCST[2:0], and the output of 
the target PC to TPC is started. When the branch instruc- 
tion bne is not taken, the SEQ code is output to PST[2:0]. 
The second taken branch instruction bne is a direct jump; 
since the target PC of the first branch instruction is being 40 
output, the target PC is not output to the TPC. The BRT 
code is output to the PCST12:0]. 

(Example 2) PC trace of indirect jump instruction 

43 

Fig. 12 shows an example of a PC trace output of 
an indirect jump instruction. For the first indirect jump 
instruction jr1 t the JMP code is output to the PCST[2:0]. 
and the output of the target PC to the TPC is started. For 
the branch instruction bne which is not taken, the SEQ so 
code is outputto PCST[2:0]. For the second indirect jump 
code jr2, the output of the target PC of the first indirect 
jump instruction is aborted, and the target PC of jr2 is 
output to the TPC. The JMP code is output to the 
PCST[2:0]. ss 
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(Example 3) PC trace of exception and indirect jump 
instruction 

Fig. 13 shows an example of a PC trace output of 
% an exception and an indirect jump instruction. When a 
software break instruction break exception occurs, the 
EXP code is output to the PCST[2:0] and the output of 
the exception vector code to the TPC is started. For the 
branch instruction bne which is not taken, the SEQ code 
is output to the PCST[2:0]. For the indirect jump instruc- 
tion jr2, the target PC of the jr2 is output to the TPC, and 
the JMP code is output to the PCSTt2:0]. 

(Example 4) PC trace when no PC is being output at the 
time a debug exception occurs 

Fig. 1 4 shows an example of the output timing of the 
PCST[2:0] when a debug exception occurs. In thisf igure, 
the DM signal is an internal signal in processor core 20, 
and when it is in a high-level, it indicates the debugging 
mode, low-level indicating the normal mode. When proc- 
essor core 20 causes a debug exception or debug reset, 
the processor enters into the debugging mode. At this 
time. PC trace circuit 32 outputs the DBM code to the 
PCSTT2:0] output. When no target PC is output, the proc- 
essor enters into the debugging mode immediately after 
the completion of the execution of the instruction which 
caused the debug exception. The PC trace information 
up to the instruction immediately before the occurrence 
of the debug is output. 

(Example 5) PC trace when a PC is being output at the 
time a debug exception occurs 

Fig. 15 shows the output timing of the PCST12:0] in 
a case in which a target PC is being output when a debug 
exception occurs. When the target PC is being output, 
the processor enters into the debugging mode after this 
target PC is completed. The PC trace information up to 
the instruction immediately before the occurrence of the 
debug exception is output. When a target PC is being 
output. STL is output to the PCST[2:0]. 

(Example 6) PC trace at the time of transition from the 
debugging mode to the normal mode 

Fig. 1 6 shows the output timing at the time of a return 
from the debugging mode. The instructions up to the 
branch delay slot instruction of the return instruction from 
the debug exception or debug reset, DERET instruction, 
belong to the debugging mode. From the instruction of 
the return address of the DERET instruction, the proc- 
essor enters into the normal mode, and the PC trace 
becomes effective. 

Detailed Explanation of the Trace Triggers 

The output of trace triggers to the PCST12:0] signal 
will be explained. 
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When either an instruction address trace trigger, 
data address trace trigger, or processor bus trace trigger 
has occurred, the trace trigger information is output to 
the PCST[2:0] by the following logic. 

5 

(1) Case in which a branch instruction which is taken 
or a jump instruction is being executed at that time, 
or an exception is occurring: Here, if a trace trigger 
does not occur, the JMP, BRT, or EXP code should 

be output to the PCST[2:0]. In this case (1), even if 10 
a trace trigger occurs, the output of the PCST[2:0] 
is not changed and is sustained, and the trace trigger 
information is output in the immediately following 
case (2) or (3). 

15 

(2) Case in which the pipeline is being stalled: Here, 
if a trace trigger does not occur, the STL code should 
be output to the PCST[2:0]. In this case (2) , rf a trace 
trigger occurs, the TST code is output to the 
PCST[2:0]. 20 

(3) Cases other than (1) and (2), i.e., cases in which 
the pipeline is performing sequential execution: 
Here, if a trace trigger does not occur, the SEQ code 
should be output to the PCST[2:0]. In this case (3), 25 
if a trace trigger occurs, the TSQ code is output to 

the PCST[2:0]. 

Embodiments will be shown below with reference to 
waveform diagrams. 30 

(Example 1) Example of occurrence of trace trigger: 
Fig. 17 shows an example in which a trace trigger 
occurs during sequential execution of ordinary 
instructions. 35 
Since the trace trigger occurred during an "add" 
instruction execution, the code TSQ of the trace trig- 
ger is output. 

(Example 2) Example of the case in which a trace 40 
trigger occurs during the execution of the instruction 
that causes the exception: Fig. 18 shows an exam- 
ple in which a trace trigger occurs during the execu- 
tion of the instruction that causes the exception. The 
trace trigger occurs during the execution of a soft- 45 
ware break instruction "break", but the code EXP for 
the exception occurrence is output onto the 
PCST[2:0] signal in the clock of the "break" instruc- 
tion execution, and the code of the trace trigger is 
output in the next clock. In this example, since the so 
status of the next clock is a stall status, the TST code 
is output. 

(Example 3) Example of the case in which a trace 
trigger occurs during an indirect jump instruction 55 
execution: Fig. 19 shows an example of a case in 
which a trace trigger occurs during an indirect jump 
instruction execution. The trace trigger occurs dur- 
ing the execution of the indirect jmp instruction jr2, 



but the code JMP of the jump is output to the 
PCST[2:0] signal in the clock of the jr2 instruction 
execution, and the code of the trace trigger is output 
in the next clock In this example, since the status of 
the next clock is an instruction execution status, the 
TSQ code is output. 

Explanati on of the Trace Memory Interface Circuit 

Fig. 20 shows a diagram of trace memory interface 

660 and trace memory 670 in: debugging tool 60. 

The TPC and PCST[2:0] outputs from debugging 
module 60 are written to trace memory 670 through trace 
data register 663. The value of the address at this time 
is supplied from trace address counter 662. The 
PCST[2:0] is also input to trace trigger decoder 664, and 
the occurrence of the trace trigger is informed to trace 
memory control circuit 661 . The setting of the initial value 
of the trace address counter and the indication of incre- 
ment/stop are performed by trace memory control circuit 

661 based on the output results of trace trigger decoder 
664. 

When controller 630 reads out the contents of trace 
memory 670, the address is set in the controller address 
register, and when a read request is sent to trace mem- 
ory controller circuit 661 , the data are read into controller 
data register 667. Then the controller reads it out. 

When controller 630 writes the data into trace mem- 
ory 670, the address is set in controller address register 
665, the data are set in controller data register 667, and 
a write request is sent to trace memory controller circuit 
661. 



Detailed Explanation of Reduction of Po wer Consump- 
tion 



Fig. 21 shows the structure of the power feed in the 
debugging module. When the debugging tool is not con- 
nected, the signal DBGE* becomes high-level. At the 
time of a user reset, if this DBGE* signal is at high-level, 
the power supply switch 38 is turned off, and no power 
is fed to the serial monitor bus circuit 34 or the PC trace 
circuit 32. Since there is no reason to use these circuits 
when no external debugging tool is connected, the power 
consumption in the microprocessor as a whole can be 
reduced by not feeding power. *. 

Even when the debugging tool is not connected, 
power is fed to instruction/data address break circuit 31 , 
processor bus break circuit 33; and register circuit 35, 
and to the functions of the instruction/data address break 
and processor bus break functions. By changing the vec- 
tor addresses of the debugging exceptions to the user 
region, the user can use these hardware break functions 
in debugging applications. 
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Detailed Explanation of the Debugging Module Initializa- 
tiQn Circuit 

Fig. 22 shows the debugging module initialization 
circuit. Since the DBGE* is at high level when the debug- 
ging module is not connected, when a user reset is 
asserted, a debugging module initialization signal is 
asserted, and the debugging module 30 is initialized. 

Even when the debugging tool is not connected, 
there is a possibility that the debugging module will 
switch into a wrong state due to power line noise or the 
like and might request an interrupt to processor core 20. 
Since the debugging tool is not connected, the debug 
reset (DRESET*) signal cannot be driven. If the debug- 
ging module cannot be initialized by a user reset, there 
is no means for initializing this debugging module. There- 
fore, when the debugging tool is not connected, it is 
extremely important tor a user reset to initialize the 
debugging module. 

Conversely, when the debugging tool is connected, 
the DBGE* becomes low-level; therefore, even if a user 
reset is asserted, a debugging module initialization sig- 
nal is not asserted, and the debugging module 30 is not 
initialized. 

This operation is extremely effective in cases where 
one wants to allow a trace trigger to occur immediately 
after a user reset, etc. If the user reset initialized the 
debugging module 30. it would be necessary, for exam- 
ple, to temporarily enter the debugging mode to reset the 
necessary register to allow a trace trigger to occur. How- 
ever, by entering the debugging mode, real time opera- 
tion would be impaired during this period, and it would 
be likely that the phenomena which is sought might not 
be captured. 

Even in cases where the debugging module itself 
malfunctions due to power line noise or the like when the 
debugging tool is connected, the debug reset 
(DRESET*) can be initialized from the debugging tool, 
and therefore there is no problem. 

Effects of Invention 

As explained above, the following effects are 
obtained by the present invention, compared to the 
examples of the prior art. 

Compared to example 1 of the prior art, the following 
effects are obtained: 

Since special debugging exceptions are provided 
for entering the monitor, restrictions are not placed on 
user interrupts. 

It is not necessary to provide a serial interface for 
the user target system. 

Hardware breakpoints can be used. 

Compared to example 2 of the prior art. the following 
effects are obtained: 

Since it is not necessary to have a sequencer in 
the microprocessor, the logic circuits for debugging 
added inside the microprocessor are simple. 



Since the registers are accessed by the monitor pro- 
gram, even when registers are added in a derivative 
processor, it is possible to easily access them merely by 
changing the monitor. 
5 » For the two reasons above, even when a number of 
kinds of peripheral circuits are added to the microproc- 
essor core, common logic circuits can be used for debug- 
ging. By putting this common module into the 
microprocessor as a part of the peripheral circuits, a 
10 common debugging tool can be applied to a variety of 
derivative microprocessors with a common processor 
core and different peripheral circuits. 

Compared to example 3 of the prior art, the following 
effects are obtained: 
is The hardware specification of debugging tools 

can be made common. 

The number of signals for connecting with debug- 
ging tools is reduced. 

For this reason, probes can be made smaller and 
20 less expensive. 

Since the microprocessor on the user target 
accesses memory and I/O, the timing conditions 
required in the debugging tool are improved. 

There are no effects on signals not connected to 
25 the debugging tool . 

If desired, the communication speed between the 
debugger tool and the microprocessor can be slowed 
down. 

For this reason, it can also be applied to high-speed 
30 microprocessors. 

Compared to example 4 of the prior art, the following 
effects are obtained: 

Using the debugging tool, access to the target 
memory and I/O and execution control can be realized. 
35 The address information for instructions which have 
been executed in the cache memory can also be traced. 

Claims 

40 1 . In a debugging system for debugging an application 
program for a microprocessor, a microprocessor 
comprising: 

first logic means for running a monitor pro- 
gram on a monitor memory in a debugging tool 
45 located outside said microprocessor; 

second logic means for controlling execution 
of a user program containing hardware breakpoints; 
and 

third logic means for tracing said user pro- 

so gram. 

2. A method for transferring signals between a micro- 
processor and a debugging tool, said debugging tool 
comprising a monitor memory for storing a monitor 
55 program to be executed in debugging mode, and fur- 
ther including an input terminal, an output terminal 
and a memory access control circuit, said method 
operative during both a memory read cycle and a 
memory write cycle, said method comprising the 
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steps of: 

during a memory read cycle: 

receiving via said input terminal, an address 
in serial format from said microprocessor; 

converting said address in serial format into 
parallel format through use of said memory access 
control circuit; 

reading addressed data from said monitor 
memory in a parallel format and converting said 
addressed data into a series format by means of said 
memory access control circuit; 

outputting said data in said serial format from 
said output terminal toward said microprocessor; 
and 

during a memory write cycle: 

inputting via said input terminal, address and 
data output by said microprocessor in serial format; 

converting said address and data in said 
serial format into parallel format by means of said 
memory access control circuit; 

writing said data to said address in said mon- 
itor memory; and 

issuing a signal indicating completion of said 
writing into said monitor memory from said output 
terminal. 
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20 



25 



between said microprocessor and said debugging 
tool; and 

deciding the timing of a start or stop of storing 
trace information into a trace memory of said debug- 
ging tool. 



4. 



A trace method for handling signals between a 
microprocessor and a debugging tool, comprising 
the steps of: 

storing an execution status of an instruction 30 
in said microprocessor into a trace memory in said 
debugging tool; 

in case said instruction is a jump or branch 
instruction, further storing into said trace memory, a 
target address of said jump or branch instruction; 35 

in case an exception has occurred, further 
storing into said trace memory, an exception vector 
number of said exception; and 

wherein all of said execution status, said 
address and said exception vector number are 40 
transmitted through a signal pin dedicated to signal 
transmissions between said microprocessor and 
said debugging tool. 

A tracing method for handling signals between a 45 
microprocessor and a debugging tool, comprising 
the steps of: 

in case the microprocessor has: 

a. executed an instruction at a preset address, so 

b. accessed data at a preset address, 

c. written preset data at a preset address, or 

d. read preset data from a preset address, 



55 



sensing occurrence of any events a-d via a 
signal pin dedicated to signal transmissions 
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